Summary of Changes

Hello @x1arch, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request refactors the sharing mechanism to properly handle parent-child relationships in shared notes by introducing a new URL path structure. It also adds a new #shareExclude attribute to control which notes are accessible via sharing, improving security and content management. Additionally, it includes updates to development documentation and .gitignore for better project maintainability.

Highlights

• Share Parent Path Fix: Implemented a new URL structure for shared notes, allowing them to be accessed via share/{share_parent_id}/{share_note}. This ensures correct parent-child relationships in shared content and updates the getSharedSubTreeRoot logic to consider the parent ID.
• #shareExclude Attribute: Introduced a new attribute #shareExclude that prevents a note from being shared or accessed directly. This is particularly useful for hiding sensitive content like scripts from shared views and is reflected in routing and note visibility filters.
• Relative Path Adjustments: Updated numerous internal links and asset paths within shared notes (e.g., CSS, JS, images, attachments, and linked notes) to correctly resolve relative URLs in the new nested sharing structure, ensuring assets load correctly.
• Documentation & Dev Experience Improvements: Enhanced the README.md with detailed dependency installation instructions for Debian and Alpine, and added troubleshooting tips for pnpm issues. The new #shareExclude attribute is also documented in the User Guide.

I faced with issue, browser do not sent Authorization header for pictures and attachments. I added cookie based authorization and query based authorization (for browsers with disabled cookies), could be configured by label #shareContentAccess, default cookie, token expiration timeout could be configured via #shareAccessTokenTimeout in seconds, by default 10 minutes. Token lives in the note, I use one token for multiple access, otherwise the token will overrides by every request and users will interfere with each other.

Added two attributes for modify share template, now it could be possible to hide left panel (#shareTemplateNoLeftPanel) or bottom prev next navigation (#shareTemplateNoPrevNext).

@x1arch , would it be possible for you to split the functionalities in different PRs?
Changing the share URL format needs thorough consideration since it can break the existing user functionality. I've noticed there is a redirect in place, but for example some people might have strict rewrite rules in the reverse proxy which might prevent them from accessing the share functionality after an upgrade.

it can break the existing user functionality.

Not sure about that, could you provide real config example which could broke anything? I've add one more section in path can't imagine rewrite rule which could be broken by that. By default it will use the same behavior like now, just take random parent and show it. I tested it with caddy and nginx it works as expected without any modifications.

would it be possible for you to split the functionalities in different PRs?

Of course I could, but that will mean, the path changed PR never will be merged, right?

for example some people might have strict rewrite rules

They could update rewrite rules, isn't it?

PS in theory we could add parent id to cookie and allow switch it to path by the label, as it made with access. I don't like this option because it is implicit behavior, but you're the boss.

it can break the existing user functionality.

Not sure about that, could you provide real config example which could broke anything? I've add one more section in path can't imagine rewrite rule which could be broken by that. By default it will use the same behavior like now, just take random parent and show it. I tested it with caddy and nginx it works as expected without any modifications.

I'll investigate.

would it be possible for you to split the functionalities in different PRs?

Of course I could, but that will mean, the path changed PR never will be merged, right?

Not necessarily, I'm not against the idea but I think we need to refine it first. Nevertheless, splitting it helps things get merged faster.

for example some people might have strict rewrite rules

They could update rewrite rules, isn't it?

They sure could, but it's best to avoid breaking changes. We have to balance the benefit of the change versus the impact.

PS in theory we could add parent id to cookie and allow switch it to path by the label, as it made with access. I don't like this option because it is implicit behavior, but you're the boss.

What about using query parameters to specify the path? That shouldn't break anything, right?

What about using query parameters to specify the path? That shouldn't break anything, right?

I don't like it, when we use path, we do not need modify template all works as is (I mean the left menu, bottom navigation), with query we need to modify every link. And it's looking ugly, like not from here, it's ok, if user don't see it (as with attachments) but for address line, no sir.

@eliandoran As you ask, I split this PR to two parts, this branch contains path update and based on #7828. This could be merged later after proxy research will be completed.